When a request comes in via a firewall, is there a way to find out where the request actually came from before the firewall got involved?

Typically you can use X-Forwarded-For if it's been setup on the firewall.

There can be but it will depend on the consistent configuration of the layers between the application and the outside world. Tomcat, for instance, can be configured via its Remote IP Valve to help get the originating IP to come through via a particular header (

x-forwarded-for

is the default). For that to work, all of the intervening firewall/proxy/load balancer/etc. layers have to be configured consistently to work with that same header.

Thanks both. I'd get to that via

getHttpRequestData()

right?

getHttpRequestData().headers, "X-Forwarded-For"

Or if the intervening layers are all configured correctly/consistently, it will just come through as

cgi.remote_addr

. That matters if, for instance, you need to enable debugging in the CF administrator for a specific IP.

Just to say,

getHTTPRequestData().headers['X-Forwarded-For']

is working for me, so thank you both 👍

Note there are some custom http headers used by specific proxies such as cloudflare as well

That's good to know, thanks. I'm also asking our network team to provide some firewall logs which should help.

We have an include with a function that handles x-forwarded and the cloudflare one..... <!--- this is because Cloudflare changes the inbound IP - they pass the real IP in CF_Connecting-IP or X-Forwarded-For (the latter of which can be a list, otherwise these two are identical, but the former is cloudflare-specific) ---> cffunction name="getClientIP" returntype="string" output="no" access="public" cfset remoteout = "" cftry cfset remoteout = ListFirst(getHttpRequestData().headers["X-Forwarded-For"],",") cfcatch/cfcatch /cftry cftry cfif remoteout eq '' cfset remoteout = getHttpRequestData().headers["CF-Connecting-IP"] /cfif cfcatch/cfcatch /cftry cfif remoteout eq '' cfset remoteout = cgi.REMOTE_ADDR /cfif cfreturn remoteout /cffunction

Suggestion • get the headers once • use structKeyExists instead of try catch error handling will always perform worse than a struct key check.